{{ d.n }}
{{ d.title }}
{{ d.code }}
Why
{{ d.why }}
What it buys
{{ d.payoff }}
AF-Bookings is a booking-management app I built to push the current Android stack against a genuinely awkward domain: polymorphic travel segments, partial data, and a user who only wants to know when to leave for the airport. Every claim below is verifiable in the repository: twenty commits, three Gradle modules.
Screens from the running app. Drag a replacement onto any slot to swap it.
The lazy answer is one fat data class with everything nullable, and a UI full of null checks that silently renders nothing when a new segment type appears. That code passes review and then rots.
The interesting question is whether the type system can carry that variety instead of the UI carrying it, so adding a segment type becomes a compile error in every place that needs updating, rather than a blank row in production.
Read the arrows as “depends on”. Nothing points upward, and nothing points into :domain
from the framework.
{{ m.name }}
{{
m.tag }}
{{ d.code }}
{{ d.why }}
{{ d.payoff }}
{{ n }}
Twenty commits, three modules, and the whole architecture readable in an afternoon. If you’re evaluating me, this is the fastest way to do it.